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REMARKS 

Claims 1, 11, 21, 38, 40, 47, 49, 51, 62 and 71 have been amended. 
Accordingly, Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 62-65 and 71-81 
are pending in the application. The reconsideration of the application is 
respectfully requested. 

On the merits, Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 62-65 and 
71-81 stand rejected under 35 U.S.C. Section 103(a) as unpatentable over Schutzer 
in view of Kolling et al. For the sake of clarity, Claims 1-46 and 48-81 were 
rejected by the Examiner. However, only Claims 1-11, 13, 17, 21-34, 38-43, 47- 
55, 57-60, 62-65 and 71-81 are pending in the application. 

In the following remarks. Applicants will show that the present invention 
provides an adaptive and dynamic common document model for electronic bill 
presentment and payment. Applicants will also provide concrete arguments that: 

1 . Neither Schutzer nor Kolling et al, singly or combined, teach or suggest 
that each of the plurality of billers has a subset of data and attributes 
accommodated by the common document model, as recited in independent 
Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71. 

2. Neither Schutzer nor Kolling et al., singly or combined, teach or suggest 
translator and a common document tree, as recited in Claim 38. 

3. Neither Schutzer nor Kolling et al., singly or combined, teach or suggest 
identifying a market segment, as recited in Claim 40, 
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4. Neither Schutzer nor Kolling et al, singly or combined, teach or suggest 
the agent interface, as recited in Claim 47. 

5. Neither Schutzer nor Kolling et al., singly or combined, teach or suggest 
allowing bill payers to customize presentment, as recited in Claim 49. 

6. Neither Schutzer nor Kolling et al, singly or combined, teach or suggest 
a modularized input engine, as recited in Claims 51, 62 and 71. 

Briefly, the present invention provides an adaptive electronic bill 
presentment and payment (EBPP) system which provides a common document 
model, allowing a plurality of billers to interface with the system of the present 
invention to cooperatively present and accept payment of bills. The present 
invention uses a rules application process to generate a translator that parses the 
biller's data stream into a common document model tree. The data and their 
attributes are mapped into nodes that fit the common document model for storage 
in the database. The use of the common format document model and the 
universality of its structure allows the plurality of billers using the present 
invention to maintain control , from a billing console functionality, over their 
billing data and how it is presented on any desired platform using any desired 
applications, formats and protocols. In other words, the present invention can 
accommodate individual data sets from, for example, both a first and second biller 
without mandating a particular template (for the billers to follow) for both billers . 
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Essentially, Applicants* common model document processing functionality 
provides for a generic conversion process that is not confined to a particular 
industry, biller, or type of customer. Thus, the present invention provides for 
dynamic structural processing and conversion of a plurality of bill data types. 

Schutzer discloses a method and system for presentment of bills wherein 
the biller account automatically formats a bill to conform to standard bill 
definition language for a consumer and automatically stores the formatted bill in a 
storage location, such as a commerce document server (CDS) (see Schutzer 
Abstract and Figs. 1-7). More specifically, a bill service provider (BSP) formats 
the bill and places the bill directly in the biller's mailbox for electronic mailing. 
Then, a consumer service provider (CSP) accesses the electronic bill produced by 
the bill service provider, along with other bills for the consumer, stores the bill(s), 
and presents the bill(s) to the consumer. Schutzer, therefore, provides a method 
and system that enables a plurality of inter-related entities and applications to 
interact with each other to provide electronic bill presentment and payment. 
Billing information are transferred from the billers to a BSP, from the BSP to a 
CDS, from the CDS to a CSP, and then finally from the CSP to the consumer. 
These separate entities and applications are authenticated by another entity, the 
certificate authority (see Schutzer Figs. 1-7). As can be seen, the billing 
information is routed through multiple applications and entities before it is finally 
presented to the consumer. In addition, because of the limitation with 
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coordinating interactions between multiple entities and applications, Schutzer 
provides a system in which incoming billing data is processed without 
transformation before it is presented to the consumer. Schutzer, in fact, formats 
the bills into a standard bill definition language to prepare it for routing through 
multiple entities and applications. 

KoUing et al. disclose an electronic statement presentment (ESP) template 
system to replace the preparation and mailing of paper statements. The system 
disclosed by Rolling et al. works exclusively with billers that have electronic 
delivery capabilities and, using statement data received electronically from a biller 
and a "stored" template , creates an electronic statement having the "look and feel" 
of a paper statement by making available a plurality of templates. More 
specifically, the system of KoUing et al. allows billers to control the "look and 
feel" of bill statements through the use of a statement template (see Kolling et al, 
column 17, lines 58-60). A parsing program is disclosed to convert statement 
augment record (SAR) data to statement content record (SCR) data. The SCR "is 
in a standard form expected by the ESP system and by the template" (emphasis 
added) (see Kolling et al., column 28, lines 52-54). Thus, Kolling et al. disclose a 
billing system implementing static data structure. The biller essentially generates 
bill statement according to a static format/template created by the biller. In fact, 
Kolling et al. clearly disclose creating " a template of static biller information to 
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serve as a basis for the electronic statement" (emphasis added) (see Kolling et al, 
Abstract). 

To put things into perspective, the words "template/templates" appear in the 
Kolling reference approximately 325 times . The word "static" made no less than 
19 appearances in the Kolling reference. 

The References do not teach an adaptive and dynamic data structure . 

With respect to independent Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71, the 
Examiner concedes that Schutzer does not teach the parsing/extracting 
functionality and the common model document element and cites the abstract, 
column 18, lines 3-56, column 23, lines 10-50 of Kolling et al. to cure this 
deficiency of Schutzer. 

Applicants have amended Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71 to 
further distinguish over Schutzer and Kolling et al. by reciting an EBBP system or 
method which enables a plurality of billers to interface with each other to 
cooperatively present and accept payment of bills using a parsing (or extracting) 
functionality and a common document model processing functionality, wherein 
each of said pluralitv of billers has a subset of data and attributes accommodated 
by said common document model . By using a common document model format, 
the present invention provides a dynamic data structure . For example, not every 
biller data has the same information and data; each biller will have a subset of all 
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data and attributes accommodated by the common document model and 
parsing/extractor functionality. Thus, the common document model and parsing 
functionality provides for a dynamic data structure which enables all billers to 
cooperatively present and accept payment of bills. 

Furthermore, Applicants' common document model processing 
functionality provides a generic conversion process that is "not confined to a 
particular industry, biller, or type of customer" (see Applicants' Specification, 
page 9, lines 3-5) and accepts any subset of data from any biller. Fundamentally, 
the common model processing allows the present invention to aggregate its fields 
of data to accommodate bills from any biller or type of customer (see Applicants' 
Specification, page 28, lines 9-17). For example, a first biller may require one 
particular subset of data while a second biller may require a similar subset data 
in additional to another subset of data that is substantially different from that of 
the first biller. Using the common model processing, the present invention can 
accommodate the individual data sets for both the first and second biller's without 
mandating a particular template for both billers. Therefore, billers retain 
autonomy on how they collect, group, display, and present their billing 
information. In short, Applicants' common document model processing 
functionality solves the problem associated with multiple billers having and 
requiring different information by accepting any subset of any data from any 
biller. 
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Schutzer discloses that the bill service provider converts the bill, along with 
enclosures, to a standard bill definition language (see Schutzer column 14, lines 
32-35). "The standard bill definition language is an extension of hypertext markup 
language/extended markup language that allows for combining templates with 
data and taking digital signatures" (see Schutzer, column 14, lines 35-38). In other 
words, Schutzer's standard definition format merely provides instructions for 
formatting the bills uniformly based on pre-determined templates. Therefore, as 
can be seen, Schutzer does not disclose a parsing functionality with a translator for 
parsing data into a common document tree with data and attributes, wherein each 
of the plurality of billers has a subset of data and attributes accommodated by the 
common document model. 

Rolling et al. do not cure the deficiencies of Schutzer. Rolling et al. do not 
parse billing data from a plurality of billers corresponding a plurality of biller data 
types and does not convert said plurality of biller data types in to a common 
document model, wherein each of the plurality of billers has a subset of data and 
attributes accommodated by the common document model. As previously 
discussed above, the parsing program of Rolling et al. converts statement augment 
record (SAR) data to statement content record (SCR) data in which the SCR is in a 
standard form expected by the ESP system and by the template. The system of 
Rolling et al. is not adaptive but rather is highlv dependent on pre-defined static 
templates . Thus, Rolling et al. do not disclose or suggest a parsing functionality 
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and a common document model that allows a plurality of billers to cooperatively 
present and accept payment of bills using a common model document 
functionality, wherein each of the plurality of billers has a subset of data and 
attributes accommodated by the common document model. 

The adaptive and dynamic data structure of the present invention can grow 
or shrink as needed to contain the data the system wants stored. That is, the 
present invention can allocate new storage when its needed and discard that 
storage when it is done with it (not every biller data has the same information and 
data; each biller will have a subset of all data and attributes accommodated by the 
common document model). Hence, use of the common document model by the 
present invention allows accommodation of all biller data types. In short, the 
dynamic data structure provided for by the use common document model allows 
the data structure of the invention of Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71 to 
grow or shrink (i.e., dynamic data structure) while Kolling et al. teach a non- 
adaptive bill format with static data structure. 

The References do not teach a Translator and a Common Document Tree, 

The Examiner failed to cite or provide any evidence for the anticipation, 
teaching, or suggestion of a translator and a common document tree which 
contains data and attributes which are mapped into nodes, as recited in 
independent Claim 38. 
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Independent Claim 38 distinguish over Schutzer and Kolling et al. by 
reciting a parsing (or extractor) functionality using rules of conversion which is a 
rules application process allowing a user to generate a translator for parsing the 
billing data into a common document tree in which the common document tree 
contains data and attributes which are mapped into nodes which fit a common 
model document for storage. 

The creation of a translator for parsing data and attributes into a form that 
can be stored in a common format storage model allows the present invention to 
efficiently present the bill to the consumer, query the stored data, control how it 
will be presented (e.g., brand building); and use the stored data as a customer 
service tool (e.g., help desk) (see Applicants* Specification, page 10, lines 3-7), 
In addition, each biller will have a subset of all data and attributes accommodated 
by the common document tree and parsing/extractor functionality because not 
every biller data has the same information and data. The parsing/extractor 
functionality provides a generic conversion process that is not confined to a 
particular industry, biller, or type of customer and accepts any subset of data from 
any biller . 

Neither Schutzer nor Kolling et al. teach or suggest the parsing 
functionality, the translator and the common document tree. Schutzer merely 
formats the bill and routes it to the consumer. Similarly, the ESP system of 
Kolling et al. merely provides a static data structure that is limited by the 
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templates . KoUing et al. do not "operate" on the biller data and do not parse the 
biller data into a common document tree with data and attributes mapped into 
nodes for a common model document. 

The References do not teach Identifyim Market Segments. 

Claim 40 further distinguishes over Schutzer and KoUing et al. by reciting 
"a biller interface coupled to said database adapted to allow said plurality of billers 
to identify market segments of said bill payers according to market rules and 
information retrieved from said database." The Examiner cites Schutzer, y?g. 25, 
and column 20, lined 16 to 55 for Claim 40; however, the Schutzer drawings and 
text referred to by the Examiner do not disclose a biller interface as recited in 
Claim 40. In fact, there is no mention of the billers being able to identify market 
segments of bill payers in the Schutzer patent. Column 20 lines 16-55 of Schutzer 
discloses a flowchart detailing the process of payment of the bill and a flowchart 
detailing the process of acknowledging payment received. Fig. 25 of Schutzer 
shows the process of the consumer transferring to a new CSP. Thus, as can be 
seen, the citations for the identifying market segments are erroneous and Claim 40 
clearly distinguish over Schutzer. 

Rolling et al. do not mention a biller interface as recited in Claim 40 either. 
KoUing et al. do not disclose or suggest allowing the biller to identify market 
segments with the biller interface. 
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Applicants, therefore, respectfully traverse the Examiner's assertion of 
anticipation as to market segment element as recited in Claim 40. 

The References do not teach an Asent Interface, 

Claim 47 further distinguishes over Schutzer and Kolling et al. by reciting 
"an agent interface coupled to said database adapted to allow a plurality of agents 
having agency relationships with said plurality of billers to communicate with said 
bill payers regarding bills." The Examiner cites Schutzer, //g^. 7-7, column 14 line 
26 to column 15, line 2, which primarily disclose a bill service provider and not an 
agent interface as claimed. Kolling et al. do not teach or suggest an "agent 
interface" either. Therefore, Applicants respectfully traverse the Examiner's 
assertion of anticipation as to an "agent interface" as recited in Claim 47. 

The References do not teach allowing Bill Payers to Customize Presentment, 

Claim 49 further distinguishes over Schutzer by reciting "bill payer 
interactivity functionality adapted to detect and respond to communications from 
said bill payers by at least retrieving from said database information corresponding 
to said bill payers and presenting said information to said bill payers in a form 
requested by said bill payers; and biller interactivity functionality adapted to detect 
and respond to communications from said plurality of billers by at least retrieving 
from said database information corresponding to said plurality of billers and 
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presenting said information to said plurality of billers in a form requested by said 
plurality of billers." The Examiner again cites Schutzer,yzg5. 7-7, and column 14, 
line 26 to column 15, line 2, which discloses that the "bill can be sent or "pushed" 
when available or held and sent when requested, i.e., "pulled" (see Schutzer, 
column 14, lines 51-53). The reference, however, does not disclose that bills can 
be presented to bill payers in a form requested by the bill payers as claimed 
(emphasis added). In fact, Schutzer only "allows billers to personally customize 
and control the content and format of the bill presentment" (Schutzer, column 3, 
lines 8-9). 

Moreover, Applicants stress the feature of Claim 49 which presents 
information to bill payers "in a form requested by said bill payers" which feature is 
not disclosed by Schutzer. As disclosed by Applicants, "customers can pay ... in a 
manner where each bill is presented to the customer in a way that is specially 
tailored to the customer with graphics, advertising, and other information that has 
been demographically proven to connect with that particular customer" (see 
Applicants* Specification, page 12, lines 13-16). Succinctly, the present invention 
allows both billers and payers to customize and control the presentation of bills 
whereas Schutzer only allows billers to customize bills. Therefore, Applicants 
respectfully traverse the Examiner's assertion of anticipation as to the 
"interactivity functionality" element recited in Claim 49. 

With regard to KoUing et al, the biller interface of KoUing et al. only 
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allows the biller to customize the presentment while the customer customize the 
payment options. In contrast, Claim 49 allows both the biller and the customer to 
customize how bills are presented . 

Thus, in addition to other patentable features as outlined above, Claim 49 is 
distinguishable over Schutzer and Rolling et al by incorporating a biller payer 
interactivity functionality. 

The References do not teach a Modularized Input Processing: Ensine . 

The Examiner failed to cite or provide any evidence for the anticipation, 
teaching, or suggestion of a modularized input processing engine , as recited in 
independent Claims 51 and 71. Moreover, the Examiner failed to cite or provide 
any evidence for the anticipation, teaching, or suggestion of the step of 
modularizing a preprocessing of electronic billing data, as recited in independent 
Claim 62. 

Claim 51 distinguishes over Schutzer and Rolling et al. by reciting "a 
modularized input processing engine, said input processing engine adapted to 
preprocess billing data from a plurality of billers corresponding to a plurality of 
data types." The advantage of using a modularized processing engine is that this 
facilitates scalability and expandability. For example, if a new form of biller data 
is encountered or must be dealt with for transformation into a form and format, the 
modularized input processing engine of Claim 5 1 allows for the processing of the 
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new biller data in a modular way (see Applicants' Specification, page 25, lines 17- 
19). There may be separate engines for each new form of data so that the output 
of each preprocessing engine is ready for processing by a rule-based parsing 
engine. In other words, because the preprocessing of biller data is modularized, a 
new input processing engine can easily be integrated to handle new data types. 
Therefore, Claim 51 is believed to be patentable for the reasons given above. 

Method Claim 62 further distinguishes over Schutzer and Rolling et al. by 
reciting the step of "modularizing a preprocessing of billing data from a plurality 
of billers corresponding to a plurality of data types." As previously discussed with 
respect to Claim 51, modularizing the preprocessing of biller data facilitates 
scalability and expandability without disrupting the present system configuration. 
Therefore, Claim 62 is believed to be patentable over Schutzer and Rolling et al. 
for the reasons given above. 

Independent Claim 71 distinguishes over Schutzer and Kolling et al. by 
reciting a modularized input processing engine, in a manner similar to Claim 51. 
Therefore, Claim 71 is believed to be patentable over Schutzer and Kolling et al. 
for the reasons given above. 

Dependent Claims, 

In view of the distinctions noted and the advantages attendant thereto, it is 
respectfully submitted that Schutzer and Kolling et al., taken singly or combined, 
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do not teach each and every aspect of the claimed invention of independent Claims 
1, 21, 38, 40, 47, 49, 51, 62 and 71, either explicitly or impliedly. 

Claims 2-11,13 and 17, v^hich are dependent upon Claim 1, are believed to 
be patentable with the parent Claim 1 . Claims 22-34, which are dependent upon 
Claim 21, are beheved to be patentable with the parent Claim 21. Claims 39, 
which is dependent upon Claim 38, is believed to be patentable with the parent 
Claim 38. Claims 41-43, which are dependent upon Claim 40, are believed to be 
patentable with the parent Claim 40, Claims 48, which is dependent upon Claim 
47, is believed to be patentable with the parent Claim 47. Claims 50, which is 
dependent upon Claim 49, is believed to be patentable with the parent Claim 49. 
Claims 52-55 and 57-60, which are dependent upon Claim 51, are believed to be 
patentable with the parent Claim 51. Claims 63-65, which are dependent upon 
Claim 62, are believed to be patentable with the parent Claim 62. Claims 72-81, 
which are dependent upon Claim 71, are believed to be patentable with the parent 
Claim 71. 

In summary, Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 62-65 and 
71-81 are believed to be allowable for the reasons given herein. Accordingly, 
these claims remain pending following entry of this Amendment, and are in 
condition for allowance at this time. As such, Applicants respectfully request 
entry of the present Amendment and reconsideration of the application, with an 
early and favorable decision being solicited. Should the Examiner believe that the 
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prosecution of the application could be expedited, the Examiner is requested to 
call Applicants' undersigned representative at the number listed below. 

Respectfully submitted, 
REINHART BOERNER VAN DEUREN s.c. 



Reg. No. 54, 879 

Customer No. 22922 

REINHART BOERNER VAN DEUREN s.c. 
Attn: Linda Gabriel, Docket Clerk 
1000 North Water Street 
Suite 2100 

Milwaukee, WI 53202 
414-298-8160 
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